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1.  INTRODUCTION 


The  purpose  of  the  Passive  Aircraft  Status  System  (PASS)  demonstration  is  to 
exhibit  the  potential  use  of  PASS  in  the  aircraft  maintenance  arena.  The  PASS 
demonstration  design  and  development  is  based  upon  data  collected  in  the  field  from 
various  field  visits,  platforms,  and  all  levels  of  maintained. 

This  paper  addresses  the  conceptual  design  and  technologies  used  in  the 
development  of  the  PASS  demonstration.  This  paper  represents  the  third  part  of  a 
three-part  PASS  effort.  Part  3  encapsulates  and  demonstrates  the  benefits  of  PASS  in 
current  and  future  maintenance  process.  Part  2  documented  the  data  collection  efforts 
and  determined  benefits  of  PASS  for  the  current  maintenance  processes.  Part  1 
determined  the  technical  feasibility  of  PASS  downlink  data  and  the  feasibility  of  putting 
the  PASS  system  on  the  aircraft. 

2.  BACKGROUND 

In  aircraft  legacy  systems,  significant  amounts  of  sensor  data  are  available  for 
capture  on-board.  The  aircraft  data  capture  in  some  legacy  aircraft  are  consolidated 
into  a  data  transfer  cartridge  or  module  that  is  eventually  downloaded  at  the  operations 
or  maintenance  debrief  system.  In  most  cases,  the  only  airborne  relay  of  critical  aircraft 
information  is  pilot  initiated  as  voice  squawk.  Within  the  current  general  concept  of 
operations,  there  is  no  air-to-ground  linkage  of  this  aircraft  maintenance  and  logistics 
data.  The  PASS  concept  attempts  to  break  this  barrier  by  sending  the  maintenance 
data  down  early  to  benefit  the  maintenance  personnel  and  serve  as  a  force  multiplier  for 
generating  subsequent  sorties. 

3.  PASS  CONCEPT 

The  PASS  concept  calls  for  detailed  aircraft  data  to  be  collected,  transferred,  and 
translated  before  landing.  Figure  1  -  Passive  Aircraft  Status  System  Concept  - 
illustrates  the  collection  of  data  from  the  aircraft,  transferring  data  to  the  ground  via 
radio  frequency  (RF)  connection,  and  the  use  of  an  interface  that  converts  the  data  into 
a  format  (i.e.,  fault  codes)  recognizable  by  maintenance  personnel. 
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Figure  1  -  Passive  Aircraft  Status  System  Concept 

While  the  aircraft  is  still  airborne,  the  converted  data  are  accessible  to  all 
maintained,  via  an  RF  or  LAN  connection  allowing  access  to  real-time  status  and  fault 
data.  Having  this  information  before  the  aircraft  lands  allows  maintainers  to  make 
informed  maintenance  decisions.  The  goal  of  the  PASS  concept  is  to  provide  accurate 
and  detailed  information  to  maintenance  personnel  in  a  consistent  and  timely  manner 
before  the  aircraft  lands.  There  is  currently  no  such  capability  in  the  today’s  legacy 
aircraft. 

In  today’s  environment,  pilots  typically  radio  a  code  squawk  when  returning  from  a 
mission.  A  code  squawk  is  a  high-level  status  providing  the  general  condition  of  the 
aircraft,  as  assessed  by  the  pilot  during  the  mission.  Several  key  maintenance 
supervisors  use  this  code  squawk  along  with  other  information  to  determine  the  type  of 
maintenance  to  be  performed  on  the  aircraft.  Unfortunately,  a  code  squawk  can  be  too 
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supervisors  unable  to  make  key  decisions  until  debrief  has  occurred,  which  often  leads 
to  valuable  time  lost. 

One  benefit  of  the  PASS  concept  is  making  detailed  information  (such  as  aircraft 
system  and  subsystem  failures,  fuels,  munitions  expenditures,  etc.)  available  to 
maintenance  personnel  while  an  aircraft  is  still  airborne.  Another  benefit  is  the  potential 
to  alleviate  critical  maintenance  issues,  such  as  determining  the  complete  health  status 
of  the  aircraft  and  all  its  major  systems/subsystems  needed  for  the  next  sortie. 

3. 1  Scope  of  Pass  Demonstration 

3.1.1  Approach 

The  selected  approach  for  the  PASS  demonstration  is  to  use  existing  laptop 
equipment  with  RF  modem  communication  to  demonstrate  the  PASS  concept  on 
current  and  future  platforms.  The  demonstration  uses  data  collected  from  Mountain 
Home,  Shaw,  and  Charleston  AFB  data  collection  trips.  Its  purpose  is  to  create  and 
show  realistic  scenarios  that  provide  a  business  case  for  PASS  implementation.  The 
demonstration  shall  also  provide  conceptual  user  screens  including  but  not  limited  to, 
the  Production  Superintendent,  Airplane  General  (APG)  Expediter,  and  the  Specialist 
Expediter.  Through  prior  fact-finding  and  data  collection  trips,  the  platforms  identified  as 
likely  to  receive  the  most  benefit  from  PASS  are  the  fighter  aircraft,  due  to  the  quick- 
turns  required  for  their  missions.  Although  F-15C,  F-15E,  and  F-16CJ  user  data  was 
collected,  the  focus  of  the  demonstration  was  to  collect  detailed  data  and  base  the 
demonstration  on  the  F-16CJ  platform.  The  demonstration  generalizes  the  PASS 
concept,  but  any  details  required  for  realism  in  the  demonstration  targets  the  F-16CJ 
platform. 

3. 1 .2  RF  T ransmission 

The  RF  air-to-ground  data  link  feasibility  was  discussed  and  proven  feasible  in  the 
first  technical  paper.  Therefore,  the  demonstration’s  focus  is  not  on  the  implementation 
of  a  specific  RF  technology,  but  rather  to  simulate  the  airborne  data  link  using  an  RF 
modem  Commercial-Off-The-Sheif  (COTS)  product. 

3.1.3  Focus 

The  demonstration’s  purpose  is  to  display  the  PASS  concept  and  conceptual 
screens. 

•  Demonstrate  the  PASS  Concept:  The  demonstration  shows  the  flow  of  PASS 
fault  information  in  the  F-16  maintenance  world.  A  scenario  concept  has  been 
identified  to  allow  generation  and  execution  of  detailed  business  cases  on  a 
PASS  simulation  application.  The  scenario  simulates  airplane  and  pilot  squawks 
for  Inflight,  Pilot,  Ground,  and  Debrief  stages  of  the  maintenance  process.  When 
the  scenario  executes,  squawks  are  generated  real  time  via  RF  to  a  receiving  RF 
modem  and  stored  into  a  database  where  it  can  be  viewed  real  time  by  various 
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maintenance  users. 


•  Conceptual  Screens:  Screens  were  developed  for  the  Pro  Super,  APG 
Expediters,  and  Specialist  Expediters.  The  conceptual  screens  show  how  and 
what  PASS  data  is  available  to  these  users. 

4.  DEMONSTRATION  ARCHITECTURE 

As  shown  in  Figure  2  —  PASS  Architecture  Concept  breaks  down  into  three  main 
areas. 


A/C 

Represents  the 
aircraft  RF 
transmission  of 
Fault  data  to  the 
ground. 


LINK  TO 
USER 

Represents  the  PASS 
ground  station  receiving 
the  Fault  data, 
interpreting  the  data, 
and  making  the  data 
available  to  the  users. 


USER 

Represents  the  actual 
users  of  the  data  (i.e., 
Pro  Super,  Expeditor, 
Backshops) 


RCAT 

Reconfigurable  Cockpit 
Avionics  Testbed  used  tc 
stimulate  the  RF 
transmission  from  the 
aircraft.  This  is  an 
example  of  a  stimulus. 


Pro  Super 


Maintenance  user  with  web 
or  RF  linkage  to  the  PASS 
data. 


Simulation  used  to 
stimulate  the  RF 
transmission  from  the 
aircraft. 


Example  of  aircraft  with 
potential  benefit  to  PASS. 


PASS 

Ground 

Station 

Receives  PASS  data. 


Formats  data  into  \ 
debrief  usable  format. 


MOC 


Maintenance  user  with  web 
or  RF  linkage  to  the  PASS 
data. 


Expeditor 

(Specialist  or  APG) 

Maintenance  user  with  web 
or  RF  linkage  to  the  PASS 
data. 


Database 


Example  of  aircraft  with 
potential  benefit  to  PASS. 


Stones  the  PASS  data. 
This  database  may  also 
contain  IMIS  data. 


IMDS  INFO, 

FLIGHT  SCHEDULES, 
MESL,  A/C  HISTORY 


.  Backshops 

(Supply) 

Maintenance  user  with  web 
or  RF  linkage  to  the  PASS 
data. 


Figure  2  -  PASS  Architecture  Concept 
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Figure  3  -  PASS  Demonstration  Concept,  divides  the  PASS  Demonstration  into  two 
main  areas.  Essentially,  the  demonstration  was  broken  down  in  this  manner  to 
demonstrate  the  RF  transmission  of  data  from  the  plane  to  the  ground. 


Holds  scenario  data 


Scenario 

Simulator 

Plays  pre-defined  scenarios 
simulation  aircraft  PASS  and 
pilot  squawks  via  RF. 
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4.1  Hardware  Architecture 

The  hardware  selected  for  the  two  main  areas  of  the  PASS  demonstration  is 
described  in  the  following  sections. 

4.1.1  Laptops  with  RF  Transmission 

Hardware  selected  to  perform  the  demonstration  used  available  equipment  with  the 
goal  of  emphasizing  the  transmission  of  PASS  information  via  RF.  Referring  to  the  two 
areas  discussed  in  Figure  3  -  PASS  Demonstration  Concept,  the  hardware  selected  for 
each  area  is  as  follows: 

•  Aircraft  (A/C)  -  Laptop  equipped  with  RF  modem.  This  laptop  serves  as  the 
aircraft  simulation.  Laptop  minimum  requirements  are  128  K  memory,  2-gig  hard 
drive,  and  RF  modem  link  to  network. 

(Note:  Throughout  this  paper,  this  laptop  is  referred  to  as 
the  Simulation  laptop.) 

•  User  —  Laptop  equipped  with  RF  modem  compatible  with  the  Simulation  laptops 
RF  modem.  Laptop’s  minimum  requirements  are  256  K  memory,  2-gig  hard 
drive,  and  RF  modem  linked  to  network.  This  laptop  serves  as  both  a 
Webserver  to  receive  and  store  the  incoming  PASS  simulation  data,  as  well  as 
housing  the  User  applications  used  to  view  the  PASS  data  through  client 
screens. 

(Note:  Throughout  this  paper,  this  laptop  is  referred  to  as 
the  WebServer/User  laptop.) 

4.2  Software  Architecture 

The  software  applications  required  for  the  PASS  demonstration  are  defined  in  Table 
1  -  Software  Application  Requirements. 
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Table  1  -  Software  Application  Requirements 


4.2.1  SIMULATION  (RF 
TRANSMISSION)  AND 
SOFTWARE  PACKAGES 

Software  packages  and 
configurations  required  to  design, 
implement  and  use  the  PASS 
Simulation  application. 

4.2.2  WEB  SERVER  AND 
SOFTWARE  PACKAGES 
USED 

Software  packages  and 
configurations  required  to  design, 
implement  and  use  the 

Webserver  application. 

4.2.3  MAINTENANCE 
USERS  AND  SOFTWARE 
PACKAGES  USED 

Software  packages  and 
configurations  required  to  design, 
implement  and  use  the  User 
Screen  applications. 

Operating  System  -  Windows  NT 
4.0  Option  Pack  6 

Operating  System  -  Windows  NT 
4.0  Option  Pack  6 

Operating  System  -  Windows  NT 
4.0  Option  Pack  6 

Development  System  -  Borlands 
JBuilder  3  Professional  (uses 

Java  SDK  1.2) 

Development  System  -  Borlands 
JBuilder  3  Professional  (uses 

Java  SDK  1.2) 

Development  System  -  Borlands 
JBuilder  3  Professional  (uses 

Java  SDK  1 .2) 

Database  -  Microsoft  Access  ’97 

Database  -  InterBase  Version 

5.0 

Database  -  Retrieves  database 
information  from  the  InterBase 
database  on  the  Webserver 

Drivers  -  ODBC  Manager,  ODBC 
driver  for  Microsoft  Access  ’97 

Drivers  -  ODBC  Manager,  ODBC 
driver  for  Microsoft  Access  ’97 
and  InterBase  JDBC 

Drivers  -  No  special  drivers 

Network  -  Connection  with  the 
WebServer/User  laptop 

Network  -  Connection  with  the 
Simulation  laptop 

Network  -  Connection  with 
Webserver  ClientAccess 
processing  required 

Webserver  -  Internet  Information 
Server  (IIS)  Version  2.0  for 
Windows  NT  Workstation  4.0 

5.  SOFTWARE  DEMONSTRATION  DESIGN  APPROACH  / 
TECHNOLOGIES  USED 

5.1  SIMULATION 

The  simulation  laptop  allows  the  generation  and  execution  of  scenarios  to 
demonstrate  the  aircraft  portion  of  the  PASS  concept. 

5.1.1  Scenarios 

A  PASS  scenario  is  defined  as  a  collection  of  squawk  events  that  are  pre¬ 
programmed  into  a  database.  A  scenario  relates  to  a  squadron  of  aircraft  returning  from 
a  sortie  and  the  PASS  data  each  aircraft  squawks  during  scenario  execution. 

Note:  The  scenario  may  also  be  applied  to  a  sortie  launch. 

Figure  4  -  Scenario  Generation  Sheet  shows  a  sample  entry  sheet  developed  to  aid 
in  the  planning  and  generation  of  a  PASS  scenario.  The  Scenario  Generation  Sheet 
allows  the  scenario  developer  to  identify  the  scenario  number,  Integrated  Maintenance 
Information  System  (IMIS)-like  data,  and  squawk  events  for  each  tail  number  in  the 
squadron. 
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•  Scenario  Number  -  Ties  the  tail  number  and  its  squawk  events  to  a  particular 
scenario.  Many  tail  numbers  belonging  to  the  same  squadron  make  up  a 
scenario. 

•  IMIS-like  data  -  Data  such  as  the  flying  schedule  and  Estimated  Time  In 
Commission  (ETIC)  are  simulated  to  allow  the  ProSuper  screen  to  display 
realistic  decision  data  that  are  made  available  through  seamless  IMIS  integration. 

•  Squawk  Events  -  The  squawks  this  aircraft  performs  for  the  identified  PASS 
scenario.  The  sheet  identifies: 

1)  Squawk  Types 

a.  Inflight  -  Fault  codes  collected  on  the  aircraft  and  transmitted  via  RF  link 
before  landing. 

b.  Pilot  -  Normal  RF  pilot  squawk  (Code  1 ,2,  or  3  with  a  subsystem). 

c.  Passive  Ground  -  Verification  of  collected  fault  data  transmitted  via  RF 
link  at  the  End  Of  Runway  (EOR). 

d.  Active  Ground  -  Human  activated  squawk  transmitting  fault  codes  via  RF 
link  while  on  the  ground.  (Used  for  Ground  Abort,  Redballs). 

e.  Debrief  -  Detailed  fault  data  and  write-ups  from  debrief  processing. 

2)  Time  of  squawk  -  Time  the  squawk  event  will  occur  from  the  beginning  of  the 
scenario. 

3)  Fault  Code  -  The  fault  codes  and  aircraft  data  that  are  transmitted  as  part  of 
the  squawk  event. 

4)  Rep  -  Indicates  “Y”  if  the  fault  is  considered  a  repeat  fault. 

5)  Recr-  Indicates  “Y”  if  the  fault  is  considered  a  recurring  fault. 

6)  Altitude  -  Altitude  of  the  aircraft  at  the  time  the  fault  occurs. 

7)  Air  Speed  -  Air  Speed  of  the  aircraft  at  the  time  the  fault  occurs. 

8)  Time  Fault  occurred  from  start  of  flight  -  time  in  flight  when  the  fault 
happened. 
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Figure  4  -  Scenario  Generation  Sheet 


Once  generated,  the  data  from  the  sheets  are  transferred  into  a  Microsoft  Access 
database.  Due  to  the  complexity  of  the  database,  a  Java  based  tool  (Scenario  Builder) 
has  been  identified  for  development  to  aid  in  the  scenario  generations.  This  tool 
replicates  the  Scenario  Generation  sheet  and  allows  entries/modifications  made  in  the 
Scenario  Builder  to  be  stored  or  modified  in  the  underlying  scenario  database. 

5.1.2  Simulation 

The  PASS  simulation  is  a  Java  application  used  to  select  and  execute  a  pre-defined 
PASS  scenario  (see  section  5.1.1).  When  started,  the  scenario  runs  at  a  defined  interval 
(default  1  second)  and  searches  the  database  for  a  list  of  squawk  events.  The  simulation 
emulates  the  squawk  events  by  displaying  an  event  at  the  time  indicated  by  the  scenario 
timer  and  transmits  the  data  via  Remote  Method  Invocation  (RMI)  over  the  RF  modem  to 
the  WebServer/User  RF  modem.  Figure  5  -  Design  for  PASS  Simulation  displays  a  block 
diagram  of  the  general  design  concept  for  the  simulation  portion  of  the  PASS 
demonstration. 


Figure  5  —  Design  for  PASS  Simulation 

The  simulation  has  a  main  thread  and  a  daemon  (or  child)  thread.  The  main  thread, 
Simulate_Pass,  sets  up  and  displays  the  Scenario  Control  Screen  (Refer  to  section 
5.1.4).  It  also  generates  and  starts  the  daemon  thread,  UpdateThread.  The  main  thread 
receives  squawk  events  and  time  information  from  UpdateThread  and  displays  them  on 
the  simulation  screen. 
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UpdateThread  queries  the  database  for  all  Squawk  events  and  sends  the  events  to 
the  main  thread  in  real-time.  UpdateThread  also  sends  time  information  to  the  Main 
Thread  showing  the  health  of  UpdateThread  and  the  current  interval  for  the  current 
scenario.  UpdateThread  also  sends  the  events  as  object  classes  to  the  RMI  server  using 
remote  object  methods  via  the  RF  modem. 

A  background  health  process  also  reports  the  health  of  the  RMI  Server/Client 
communication  between  the  Simulation  and  the  WebServer/User  laptops. 

5.1.3  Data  Transmission  (RMI  CLIENT) 

Remote  Method  Invocation  (RMI)  transmission  is  the  chosen  transfer  method  for 
passing  squawk  event  and  health  data  from  the  simulation  processing  to  the 
WebServer/User  processing.  RMI  is  used  to  pass  data  between  the  Simulation  laptop 
and  the  Webserver  laptop.  RMI  allows  a  server  to  register  classes  with  remote  methods 
and  bind  them  to  the  RMI  registry.  A  remote  computer  may  locate  and  gain  access  to  this 
object  by  accessing  and  invoking  remote  methods  available  for  the  object.  Remote 
methods  may  contain  input  and  return  parameters  that  allow  the  transfer  of  entire  objects 
from  one  application  or  machine  to  another. 

A  class  encapsulating  the  squawk  event  implements  a  remote  interface  with  remote 
methods  to  transfer  data  from  the  simulation  laptop  to  the  WebServer/User  laptop.  The 
Webserver  processing  contains  the  server  portion  of  the  squawk  event  transfer  and  the 
simulation  contains  the  client  portion  of  the  squawk  event  transfer.  The  Webserver 
registers  the  squawk  event  class  with  the  RMI  registry  to  make  a  transfer  method 
available  to  a  remote  computer  for  client  invocation.  The  UpdateThread  daemon  thread 
packages  the  squawk  event  data  into  the  squawk  event  class  and  uses  RMI  technology  to 
transfer  the  entire  object  to  the  Webserver.  The  Webserver  retrieves  the  data  and  stores 
the  data  into  the  PASSReceiver  database. 

A  similar  class  with  few  or  no  parameters  exists  for  the  health  check.  The  RMI  server 
or  client  may  reside  on  either  the  Webserver  or  the  simulation  laptop.  Remote  calls  for 
health  checks  are  invoked  by  the  client  and  the  data  are  reflected  on  the  Simulation 
Screen  in  the  form  of  text  or  animation. 

5.1.4  Conceptual  Screens 

Figure  6  -  PASS  Simulation  Screen  depicts  an  executing  PASS  scenario.  This  screen 
is  an  example  of  the  conceptual  simulation  data  to  be  included  on  the  simulation  screen. 
The  simulation  screen  is  a  continuous  real-time  display  of  the  events  occurring  in  the 
scenario  and  at  what  times. 
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Table  2  -  Simulation  Screen  Conceptual  Areas 


Scenario  Control 

Scenario  Status 

Scenario  Data 

Select  Scenario  -  User  may 
select  which  scenario  to  run  from 
a  list  of  pre-defined  scenarios 
located  in  the  Simulation 
database. 

Time  -  Shows  the  current 
scenario  time.  The  scenario  time 
jumps  by  the  interval  defined  in 
the  Select  Interval  button.  A 
running  time  indicates  the 
UpdateThread  is  healthy. 

A  time  ordered  list  of  Squawk 
events  and  all  data  reported  for 
that  squawk  event.  This  data  is 
generated  and  displayed  when 
the  scenario  clock  matches  or  is 
greater  than  the  time  attached  to 
an  event  in  the  currently  running 
scenario. 

Start  Scenario  -  User  may  start 
the  scenario.  This  button  also 
used  to  resume  the  scenario. 

Health  -  Show  the  health  status 
of  the  RMI  connection  at  a  pre¬ 
defined  interval.  Health  status 
may  be  textual  or  in  the  form  of 
animation  (not  shown  in  picture). 

Pause  -  User  may  Pause  the 
Scenario  while  the  scenario  is 
running. 

Stop  -  User  may  stop  the 
scenario  while  the  scenario  is 
running. 

Select  Interval  -  Interval  at  which 
the  scenario  clock  runs.  The 
default  value  is  1  second.  The 
user  may  increase  the  interval  in 
whole  seconds.  This  is  used  to 
make  the  scenario  run  faster  and 
is  available  while  the  scenario  is 
running. 

5.1.5  Scenario  Database 

The  scenario  database  holds  the  pre-generated  PASS  scenario  data  for  use  with  the 
PASS  Simulation  software.  The  database  contains  many  lookup  tables  to  ensure  that 
only  specific  items  may  be  added  to  various  tables.  Figure  7  -  PASS  Simulation 
Database  Relationships  with  Lookup  Tables  shows  the  database  design  for  the  scenario 
database  with  lookup  tables.  Figure  8  —  PASS  Simulation  Database  Relationships 
without  Lookup  Tables  shows  the  database  design  with  the  lookup  tables  removed  to  give 
a  better  view  of  the  main  tables  used  in  the  PASS  simulation. 
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Microsoft  Access  ’97  was  selected  for  the  scenario  database.  Access  was  selected 
for  ease  of  use  and  quick  programmability  and  usability.  The  simulation  is  merely  a 
stimulation  tool  to  populate  the  PASSReceiver  database  located  on  the  Webserver 
laptop.  Any  relational  database  such  as  Oracle,  SQL  Server,  and  InterBase  etc.  may  be 
used  in  place  of  Access. 

5.1.6  Simulation  Limitations 

RMI  only  allows  data  transfer  between  Java  Virtual  Machines.  The  PASS 
demonstration  only  contains  Java  Virtual  Machines;  therefore,  the  use  of  RMI  meets  the 
requirements.  However,  for  PASS  implementation  involving  legacy  systems,  CORBA 
methodology  must  be  investigated  due  to  its  flexibility  of  allowing  many  different 
languages  (i.e.  Java,  C++,  Visual  Basic)  to  communicate  with  each  other.  Jini,  a  more 
flexible  Java  interconnection  language,  may  also  be  considered. 

Real-time  additions  to  the  scenario  will  be  available  scenario  is  running,  but  these 
additions  will  not  be  stored  to  the  scenario  in  the  simulation  database. 

5.2  Webserver 

The  Webserver  acts  as  the  central  data  processor  to  receive,  decode,  store,  and 
distribute  PASS  information.  Webserver  processing  receives  the  data  from  the 
simulation  via  RF  and  stores  the  data  into  the  PassReceive  database.  The  Webserver 
also  distributes  the  stored  data  to  any  clients  requesting  PASS  information. 

Figure  9  -  Design  for  PASS  Webserver  shows  the  Webserver  design.  The 
Webserver  application  shares  its  residence  with  the  Maintenance  User  applications  on 
the  second  laptop.  The  design  for  the  communication  between  the  Webserver  and 
Maintenance  Users  processing  implements  RMI  and/or  Web  technology. 
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Figure  9  -  Design  for  PASS  Webserver 

The  Webserver  has  a  main  thread  and  two  daemon  threads.  The  main  thread 
generates  and  starts  two  daemon  threads  1)  the  UpdateDatabase  thread  and  2)  the 
ClientAccess  thread. 

The  UpdateDatabase  thread  retrieves  the  squawk  events  from  the  PASS  simulation 
and  stores  the  data  in  the  appropriate  tables  in  the  PASSReceiver  database.  The  RMI 
Server  is  part  of  this  thread,  which  creates  and  registers  the  server  implementing  remote 
methods  for  receiving  squawk  events.  This  thread  also  receives  Static  Plane  Data  before 
scenario  execution  and  updates  the  StaticPIaneData  table  in  the  PASSReceiver 
database.  RMI  responses  to  health  checks  are  also  handled  via  this  thread. 

The  ClientAccess  Thread  processes  all  retrieval  and  update  requests  for  the 
Maintenance  User  screens.  This  includes  PASS  Login  verification  and  changes  made  by 
the  users.  See  client  screens  section  5.3  for  more  details  on  user  updateable  data  in  the 
maintenance  screens. 

Note:  All  updates/retrieval  classes  in  the  database  must  be 
synchronized  to  ensure  database  integrity  throughout  the 
system. 

The  Webserver  processing  keeps  a  copy  of  its  classes  in  the  root  directory  of  the 
Internet  Information  Server  (IIS).  These  classes  provide  client  computers  access  to 
remote  stubs  and  classes  needed  for  RMI  technology  implementation. 
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5.2.1  Data  Reception  (RMI  SERVER) 

RMI  transmission  is  the  chosen  transfer  method  for  passing  squawk  event  and  health 
data  from  the  simulation  processing  to  the  WebServer/User  processing.  RMI  allows 
classes  with  remote  methods  to  be  registered  and  bound  to  the  RMI  registry.  A  remote 
computer  may  gain  access  to  these  methods  by  creating  an  object  containing  remote 
interfaces  and  invoking  the  methods.  Remote  methods  may  contain  input  and  return 
parameters  that  may  be  used  to  transfer  entire  objects. 

A  class  encapsulating  the  squawk  event  implements  a  remote  interface  with  remote 
methods  to  transfer  data  from  the  simulation  laptop  to  the  WebServer/User  laptop.  The 
Webserver  processing  contains  the  server  portion  of  the  squawk  event  transfer  and  the 
simulation  contains  the  client  portion  of  the  squawk  event  transfer.  Webserver 
processing  registers  the  squawk  event  class  with  the  RMI  registry  to  make  a  transfer 
method  available  to  a  remote  computer  for  client  invocation.  The  daemon  thread 
packages  the  squawk  event  data  into  the  squawk  event  class  and  utilizes  RMI  methods  to 
transfer  the  entire  object  to  the  Webserver.  The  Webserver  also  retrieves  and  stores  the 
data  into  the  PASSReceiver  database. 

A  similar  class  with  few  or  no  parameters  exists  for  the  health  check.  The  RMI  server 
or  client  may  reside  on  either  the  Webserver  or  the  simulation  laptop.  Remote  calls  for 
health  checks  are  invoked  by  the  client  and  the  data  are  reflected  on  the  Simulation 
Screen  in  the  form  of  text  or  animation. 

5.2.2  Data  Storage 

The  PASSReceiver  database  stores  the  simulation  data  for  request  and  retrieval  from 
the  Maintenance  User  Screens.  Figure  10  —  PASSReceiver  Database  Relationships  with 
Lookup  Tables  shows  the  relationship  diagram  for  the  PASSReceiver  database  with  all 
lookup  tables  displayed.  The  layout  of  the  database  tables  (seven  main  tables),  to 
include  a  brief  explanation  of  each  is  shown  in  Figure  11  -  PASSReceiver  Database 
Relationships  without  Lookup  Tables. 

The  database  tool  used  for  the  PASS  demonstration  is  an  open  source  database, 
InterBase,  packaged  with  the  JBuilder  tool.  Due  to  the  nature  of  the  Webserver 
processing,  the  database  tool  must  be  compatible  with  SQL  programming/commands. 
InterBase  5  was  chosen  due  to  the  availability  and  compatibility  with  SQL.  The  version 
used  for  the  PASS  demonstration  only  provides  a  local  server;  therefore,  the  database  is 
not  accessible  remotely. 

Note:  For  PASS  implementation,  especially  for  the  integration 
of  PASS  with  IMIS-type  legacy  systems,  conclusive  studies 
should  be  performed  on  commercially  available  databases 
such  as  Oracle,  SQL  Server  and  the  full  version  of  InterBase 
to  ensure  a  complete  enterprise  PASS  implementation  can  be 
obtained.  The  PASSReceiver  database  ultimately  should 
reside  on  a  separate  machine  from  the  Webserver. . 


18 


19 


«V'! 


I 


if 


o>  to " 

T*c£ 
Q  a)  co 
Ql  >  -o 
£  Q>  o 
p  «£  E 


™  i  » 

=5  5  2 

p  3  *r 


iffl? 

|  S|« 
5  »  §  §! 

to  2  o*  o 
— CO  Q>  I 
to  CO  *g  W  ! 

is  £?c 

3  O  ^  ' 

~  A  o  ro  i 
-u.  0>Bcnl 

O  Jr  ^  .£  < 

—  2  i  E" 

S)  r  <5  3  j 
**£  fc  3  o 


«  >  o* 

©  o  ^  w  < 
i:  «  «  -  " 


b  -o  £  «  2 
P  W  *o  •=  r 


<  &  is  «  «  ft 


<D  O 
x:  ‘c 

ogco) 
to  g  g£ 

•g|«H 

■p  E  a>  Q> 

l«*s 


0) 

CO 

3  "O 
a>  <u 
o  c 

ss 

C  TJ 

a> 


<D 


to 

U 

X) 


CO 
0)  0)  o 

“  £  Ql 
O  ® 


S3  £2  <d 

XJ  <D 
(0  2>  co  CO 

|  S  g! 

«  £  c  re 
a>  to  is 
o  c  co 

0  C 

to  to  o 
P  <u  .§  P 

O  §-  g  <5 

X  .£*  E  -a 


a) 

E 

to 

*0^0) 

TO  ffl  ~ 
WO 

r-D  W 

o  -c  2 

.rod 
TJ  ffl  > 

£“^1 

i”S 

O  O  X 
<  ^5  ro 

--g-'S 

.5  uj  c 

O^O) 

®  Sr  to 

Cl  0-  y> 

CO  <  to 


0)  J- 

£  5 

8  S* 

£  oL 

«  to 

3  T3 

-o 
p  to 
c  -o  . 

a>  a>  c 
to  J9  ‘co 
*0  3  0) 
0.0.° 
O  O  — 

a.  °-  a> 

D.  fl)  CO 

(0X1  3 


52  c  h 

£  f  to 

3  2  ® 

“II 

OfflU 

■£  <D  .E 

_  _  <i>  «  CO 

$3-g3$ 

.C  «5  S  «  £.5  CL 
<0  ~  .C  T3  _  (0  °- 

g  «  S 

8  &g 

I|i 

nz  O 
0^0) 

8."  I 

3  W 

CO  £  c 
p  O  ro 
a.  w  E 


3  S3 .2 
jS  to  ■§=  <5 

w  to  =  3 
0)  "D  U_  £ 
£  CO  ®  co 

C  —  C  -c: 

fl)  __  C  -■"  ” 

to-g  o  C 

£  .g  *=  “ 

q.  jq  ro  ^ 

®  3  to  -9 
X  co  -o  £ 


T3 

c 
co 

o  g«o| 

s  n  <0 

|«Se 

Q)  E  T5  -2 

E  c  ®  o 

I  §  g  I 

O..S2  s  10 

pop 
•=  a)  3  w 
WT)  -O  co 

$£|| 
a.  -o  «  r 
to  $££ 

g  3P1- 
O  «  c  0) 
r  ”  co  *; 
to  ro  co  5 
><U  (0  o 

“  ®  I  -s  .  _ 
pf  £  §  s>  ° 

(U  >  O  O  C  o 
S  O  D  £  0)  r  _ 
E  .c  co  co  to  £=  XI 


:  0)  X 


(0 


8  TO 
fl>  TO 

c  jd  -a 

]  £  co 

«W 

jg? 


1 

t 

1 


20 


Figure  11  -  PASSReceiver  Database  Relationships  without  Lookup  Tables 


The  PASS  simulation  transfers  the  StaticPIaneData  via  RMI  when  the  Start  Scenario 
button  is  selected.  Upon  Receipt,  the  Webserver  processing  stores  the  data  in  the 
PASSReceiver  database.  When  a  user  logs  in,  the  maintenance  users  screen  is 
populated  using  the  data  from  this  table  to  show  valid  flying  schedules,  ETICs,  etc.  There 
is  also  default  data  in  the  databases  in  case  the  Scenario  is  generated  without  specific 
data. 


5.2.3  Web  Server  Limitations 

The  use  of  InterBase  for  a  local  database  server  is  constrained  in  that  the 
PASSReceiver  database  cannot  be  updated  remotely.  The  PASS  demonstration  design 
forces  all  updates  to  the  database  to  be  handled  through  either  the  UpdateDatabase 
thread  or  the  ClientAccess  thread.  Therefore,  the  database  cannot  be  move  to  a 
separate  machine  unless  the  full  version  of  InterBase  or  another  remote  accessible 
database  is  used. 


5.3  Maintenance  Users 

The  maintenance  users  may  access  the  PASS  maintenance  data  through  the 
Maintenance  User  applications.  These  applications  consist  of  Web  pages  and  or  Java 
applications  using  many  technologies  such  as  Java  applets,  VBScript,  JavaScript,  and 
Hypertext  Markup  Language  (HTML)  as  appropriate.  The  following  sections  provide 
prototype  screens  for  each  of  the  Maintenance  Users  screens  required  for  the  PASS 
demonstration.  These  screens  are  conceptual  and  represent  the  general  concepts  of  the 
PASS  demonstration  and  the  information  it  provides.  Due  to  the  nature  of  this  paper,  and 
the  ongoing  implementation  of  the  demonstration,  final  screens  will  be  defined  on  the 
completion  of  the  PASS  demonstration  system. 


5.3.1  Entering  System 

Figure  12  -  PASS  Login  Screen  is  provided  to  allow  entry  into  the  PASS  application 
upon  verification  of  a  User  Name  and  Password.  The  login  screen  performs  two 
functions.  The  first  function  allows  the  user  to  enter  the  system  for  security  access  and 
privilege  levels.  The  second  function  identifies  the  type  of  user  to  the  PASS  application. 
Based  on  the  user  login  and  password,  the  PASS  application  determines  the  users 
assigned  type  and  shows  the  appropriate  PASS  user  screen. 


Figure  12  -  PASS  Login  Screen 
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5.3.2  Pro  Super  Screens  and  Privileges 

If  the  user  logs  in  as  a  Pro  Super,  a  screen  similar  to  Figure  13  -  Pro  Super  PASS 
Concept  Screen  is  displayed. 
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Figure  13  -  Pro  Super  PASS  Concept  Screen 

The  larger  screen  labeled  Pro  Super  mimics  an  electronic  version  of  the  current 
clipboard  status  sheet  used  in  today’s  maintenance  environment.  A  row  for  each  tail 
number  assigned  to  the  Pro  Super  is  displayed  along  with  any  pre-set  scenario  data  for 
each  plane.  The  button  labeled  PASS  has  been  added  to  the  electronic  Pro  Super  status 
sheet.  The  Pro  Super  may  select  the  PASS  button  to  display  the  smaller  PASS  DATA 
window.  The  PASS  DATA  window  displays  data  for  a  specific  tail  number.  The  PASS 
data  available  to  the  Pro  Super  and  the  privileges  (defined  in  Italics)  are  as  follows: 

•  TailNumber  -  identifies  the  tail  number  of  the  aircraft  the  data  is  detailed  for  (Read 
Only) 

•  Code  1 .  2.  and  3  buttons  -  Allows  the  Pro  Super  to  select  the  current  status  code 
of  the  plane  based  on  the  squawk  entries  and  the  data  available  on  the  status 
sheet.  The  code  defaults  to  the  lowest  code  in  the  code  column  based  on  the 
latest  squawk  information.  The  Pro  Super  may  either  exit,  accepting  the  default 
selection,  or  make  a  code  selection.  Upon  exit  or  selection  of  the  code,  the  status 
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sheet  updates  the  PASS  button  with  the  proper  color  and  code  and  updates  all 
other  displays  real-time.  (Pro  Super  selection) 

•  Faults  (Read  Only):  The  faults  block  is  used  to  display  the  PASS  or  Pilot  fault  data 
transmitted. 

1 )  Squawk  -  Indicating  type  of  squawk. 

a.  Inflight  -Fault  codes  collected  on  the  aircraft  and  transmitted  via  RF  link 
before  landing. 

b.  Pjlot  -  Normal  UHF  pilot  squawk  (Code  1 ,2,  or  3  with  a  subsystem). 

c.  Passive  Ground  -  Verification  of  collected  fault  data  transmitted  via  RF 
link  at  EOR. 

d.  Active  Ground  -  Human  activated  squawk  transmitting  fault  codes  via 
RF  link  while  on  the  ground.  (Used  for  Ground  Abort,  Redballs). 

e.  Debrief  -  Detailed  fault  data  and  write-ups  from  debrief  processing. 

2)  Time  of  squawk  -  Time  the  squawk  occurred. 

3)  Code  -  Minimum  Essential  Systems  List  (MESL)  Code  pertaining  to  this  fault 
code. 

4)  Fault  Code  -  Alphanumeric  code  indicating  the  failure. 

5)  Fault  Description  -  Word  description  of  the  fault. 

6)  Repeats -Yes,  if  fault  occurred  in  last  flight.  No,  otherwise. 

7)  Recur  -  Yes,  if  same  fault  occurred  within  last  five  flights.  No,  otherwise. 

•  Expenditures  (Read,  Only):  The  expenditure  block  is  used  to  display  the  PASS  or 
Pilot  expenditure  data  transmitted. 

1}  Squawk  -  Indicating  type  of  squawk. 

a.  Inflight  -  Expenditure  data  transmitted  via  RF  link  before  landing. 

b.  Passive  Ground  -  Verification  of  collected  expenditure  data  transmitted 
via  RF  link  at  EOR. 

2)  Fuel  -  Percentage  of  fuel  remaining  are  displayed  in  percentage  remaining. 

3)  Bombs-  Number  of  bombs  expended. 

4}  Bullets-  Number  of  bullets  expended. 
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5}  Missiles  -  Number  of  missiles  expended. 

6}  Flares  -  Number  of  flares  expended. 

7}  Chaff  -  Number  of  chaff  expended. 

Note:  For  full  PASS  design  and  implementation,  weapons 
data  needs  to  be  based  on  configuration  of  aircraft  to  show  x 
of  y  expenditures  (i.e.  2  of  5  missiles)  instead  of  just  the 
amount  expended. 


5.3.3  APG  Expeditors  Screens  and  Privileges 

If  the  user  logs  in  as  an  APG  Expeditor,  a  screen  similar  to  Figure  14  -  Expeditor 
PASS  Concept  Screen  is  displayed. 
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Figure  14  —  Expeditor  PASS  Concept  Screen 

The  larger  screen  labeled  APG  Expeditor  mimics  an  electronic  version  of  the  current 
clipboard  status  sheet  used  in  today’s  maintenance  environment.  A  row  for  each  tail 
number  assigned  to  the  APG  Expeditor  appears  in  this  area  along  with  any  pre-set 
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scenario  data  for  each  plane.  The  button  labeled  PASS  has  been  added  to  the  electronic 
APG  Expeditor  status  sheet.  When  new  PASS  data  is  available,  the  APG  Expeditor  may 
select  the  PASS  button  to  display  the  smaller  PASS  DATA  window.  The  PASS  DATA 
window  displays  data  for  a  specific  tail  number:  The  PASS  data  available  to  the  APG 
Expeditor  and  the  privileges  (defined  in  italics)  are  as  follows: 

(Note  the  similarity  in  the  APG  Expeditor  and  ProSuper 
screens.  In  essence,  the  APG  Expeditor  has  the  same  data 
available  to  the  ProSuper  for  fewer  tail  numbers.  However, 
the  APG  Expeditor  does  not  make  the  final  determination  of 
the  code,  the  ProSuper  does.  The  code  displayed  to  the 
APG  expeditor  is  the  same  as  what  is  shown  on  the 
ProSuper  screen  in  real-time.) 

•  TailNumber  -  identifies  the  tail  number  the  data  is  detailed  for  (Read  Only). 

•  Code  -  The  current  status  of  the  aircraft  as  determined  by  the  ProSuper  (Read 
Only). 

•  Faults  (Read  Only}:  The  faults  indicate  the  PASS  or  Pilot  data  transmitted. 

1)  Squawk  -  Indicating  type  of  squawk. 

a.  Inflight  -Fault  codes  collected  on  the  aircraft  and  transmitted  via  RF  link 
before  landing. 

b.  Pilot  -  Normal  UHF  pilot  squawk  (Code  1 ,2,  or  3  with  a  subsystem). 

c.  Passive  Ground  -  Verification  of  collected  fault  data  transmitted  via  RF 
link  at  EOR. 

d.  Active  Ground  -  Human  activated  squawk  transmitting  fault  codes  via 
RF  link  while  on  the  ground.  (Used  for  Ground  Abort,  Redballs). 

e.  Debrief  -  Detailed  fault  data  and  write-ups  from  debrief  processing. 

2}  Time  of  squawk  -  Time  the  squawk  occurred. 

3)  Code  -  MESL  Code  pertaining  to  this  fault  code. 

4}  Fault  Code  -  Alphanumeric  code  indicating  the  failure. 

5)  Fault  Description  -  Word  description  of  the  fault. 

6)  Repeats  -Yes,  if  fault  occurred  in  last  flight.  No,  otherwise 

7}  Recur  -  Yes,  if  fault  occurred  within  last  five  flights.  No,  otherwise. 
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•  Expenditures  (Read  Only): 

1)  Squawk  -  Indicating  type  of  squawk. 

a.  Inflight  -Fault  codes  collected  on  the  aircraft  and  transmitted  via  RF  link 
before  landing. 

b.  Passive  Ground  -  Verification  of  collected  fault  data  transmitted  via  RF 
link  at  EOR. 

2)  Time  of  squawk  -  Time  the  squawk  occurred. 

3)  Fuel  -  Percentage  of  fuel  remaining. 

4)  Bombs-  Number  of  bombs  expended. 

5)  Bullets-  Number  of  bullets  expended. 

6)  Missiles  -  Number  of  missiles  expended. 

7)  Flares  -  Number  of  flares  expended. 

8)  Chaff  -  Number  of  chaff  expended. 

Note:  For  full  PASS  design  and  implementation,  weapons 
data  needs  to  be  based  on  configuration  of  aircraft  to  show  x 
of  y  expenditures  (i.e.  2  of  5  missiles)  instead  of  just  the 
amount  expended. 

5.3.4  Specialist  Expeditor  Screens  and  Privileges 

If  the  user  logs  in  as  a  Specialist,  a  screen  similar  to  Figure  15  -  Specialist  PASS 
Concept  Screen  is  displayed. 
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Figure  15  -  Specialist  PASS  Concept  Screen 

The  larger  screen  labeled  Specialist  mimics  an  electronic  version  of  the  current  grease 
board  or  clipboard  status  sheet  used  in  specialist  expediter  trucks  in  today’s  maintenance 
environment.  A  row  for  all  tail  numbers  assigned  to  the  Specialist  appears  in  this  area 
along  with  any  pre-set  scenario  data  for  each  plane.  The  button  labeled  PASS  has  been 
added  to  the  electronic  Specialist  status  sheet.  When  new  PASS  data  is  available,  the 
Specialist  may  select  the  PASS  button  to  display  the  smaller  PASS  DATA  window.  The 
PASS  DATA  window  displays  data  for  a  specific  tail  number.  The  PASS  data  available  to 
the  Specialist  and  the  privileges  (defined  in  italics)  are  as  follows: 

•  TailNumber  -  identifies  the  tail  number  the  data  is  detailed  for  (Read  Only). 

•  Code  -  The  current  status  of  the  aircraft  as  determined  by  the  Pro  Super  (Read 
Only). 

•  Faults  ( Read  Only ):  The  faults  indicate  the  PASS  or  Pilot  data  transmitted. 
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1)  Squawk  -  Indicating  type  of  squawk. 

a.  Inflight  -Fault  codes  collected  on  the  aircraft  and  transmitted  via  RF  link 
before  landing. 

b.  PHot  -  Normal  RF  pilot  squawk  (Code  1 ,2,  or  3  with  a  subsystem). 

c.  Passive  Ground  -  Verification  of  collected  fault  data  transmitted  via  RF 
link  at  EOR. 

d.  Active  Ground  -  Human  activated  squawk  transmitting  fault  codes  via 
RF  link  while  on  the  ground.  (Used  for  Ground  Abort,  Redballs). 

e.  Debrief  -  Detailed  fault  data  and  write-ups  from  debrief  processing. 

2}  Time  of  squawk  -  Time  the  squawk  occurred. 

3}  Code  -  MESL  Code  pertaining  to  this  fault  code. 

4)  Fault  Code  -  Alphanumeric  code  indicating  the  failure. 

5)  Fault  Description  -  Word  description  of  the  fault. 

6)  Repeats  -Yes,  if  fault  occurred  within  last  flight.  No,  otherwise. 

7}  Recur  -  Yes,  if  fault  occurred  within  last  five  flights.  No,  otherwise. 

8)  Air  Speed  -  Speed  of  aircraft  when  fault  occurred. 

9)  Altitude  -  Altitude  of  aircraft  when  fault  occurred. 

10)  Time-  Time  when  fault  occurred. 

5.3.5  Weapons  Expeditors  Screens  and  Privileges 

The  Weapons  Expeditors  Screens  are  not  depicted  separately  because  they  are  very 
similar  to  the  specialist  expeditor. 

5.3.6  Debrief  Screens  and  Privileges 

The  Debriefer  Screens  were  determined  out  of  scope  for  this  effort. 

5.3.7  User  Limitations 

Users  may  update  or  view  items  based  on  privileges  identified  for  the  user  type. 
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5.4  Databases 


5.4.1  Storage  and  retrieval  of  data 

Data  is  retrieved  through  the  ClientAccess  thread  of  the  Webserver  processing.  The 
Java  application  or  applet  requests  the  current  situation  data  for  the  assigned 
tailnumbers.  The  ClientAccess  thread  identifies  a  requestor’s  user  type  and  returns  the 
appropriate  information. 

Any  updates  made  by  a  user  are  stored  by  the  ClientAccess  processing  and  if 
required,  sent  to  any  other  user  on  the  system  real-time. 

5.4.2  Database  Limitations 

Using  InterBase  as  a  local  Webserver  does  not  allow  the  database  to  be  placed  on  a 
separate  machine  from  the  Webserver  logic  (i.e.  business  logic)  for  remote  access.  This 
limitation  is  discussed  in  further  detail  in  Section  6.4. 

6.  CONSIDERATIONS  FOR  DESIGNING  DEPLOYED  SYSTEM  NOT 
ADDRESSED  IN  DEMONSTRATION 

Several  shortcuts  were  taken  due  to  the  time,  schedule,  budget,  and  equipment 
constraints  during  the  design  and  implementation  of  the  PASS  demonstration.  Table  3  - 
Shortcut  and  Design  Considerations  focus  on  major  areas  where  known  shortcuts  were 
taken  along  with  notes  on  what  items  should  be  considered  in  a  full-scale  design  and 
implementation  of  PASS. 


Table  3  -  Shortcut  and  Design  Considerations 


Shortcut 

Design  Considerations 

6.1  Security 

Login  accounts  for  PASS  were 
implemented  as  a  simple 
database  lookup  table. 

Windows  NT  accounts  or  other 
security  measures  should  be 
investigated. 

RF  transmission  was  not 
encrypted. 

Due  to  the  nature  of  the  PASS 
maintenance  data,  the  PASS  data 
should  be  encrypted  via  the  data- 
link.  Upon  selection  of  PASS 
equipment,  encryption/decryption 
hardware/software  should  be 
investigated. 
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Shortcut 

Design  Considerations 

6.2  Users 

Screens  targeted  ProSuper,  APG 
Expeditor,  and  Specialist. 

All  levels  of  Maintenance  users 
can  benefit  from  the  PASS 
concept.  Weapons  and  Debrief 
were  mentioned  in  the  paper  in 
small  detail.  Backshops,  as  well 
as  the  maintainer  all  show 
potential  PASS  benefit.  Other 
areas  such  as  Operations,  MOC 
and  Safety  should  be  considered 
as  benefactors  for  PASS  design, 
implementation  and  integration  of 
PASS  with  IMIS. 

Screens  are  conceptual. 

The  screens  are  conceptual. 

Actual  demonstrations  of  the 

PASS  demonstration  may  define 
other  views  or  ideas.  These 
comments  should  be  tracked  and. 
considered  for  PASS 
implementation. 

Switchology  was  not  implemented 
for  the  Specialist  menus. 

Switchology  needs  to  be 
addressed  when  defining  the  data 
collection  requirements  for  PASS 
implementation. 

Flight  duration  was  not  addressed 
in  conceptual  screens. 

Many  maintenance  schedules  are 
mandated  by  flight  time. 

Debriefers  expressed  the 
requirement  for  a  Weight  Off 
Wheels  time  entry  and  a  Weight 

On  Wheels  time  entry  as  part  of 
PASS  implementation.  This 
would  aid  in  consistent  flight 
duration  calculations  throughout 
the  maintenance  process  and 
alleviate  small  additions  of  flight 
times  (i.e.  5  minutes)  being  added 
to  flight  logs  decreasing 
maintenance  intervals  over  time. 

Flight  Parameters/Switchology 

Switchology  was  also  a  desire  for 
the  Specialists.  Due  to  time  and 
schedule  a  limited  set  of  flight 
parameters  were  defined.  For 
PASS  design  and  implementation, 
more  in-depth  investigation  of  the 
available  flight  parameters  and 
switchology  needed  is  required. 
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6.3  RF  Data  Link  Integrity/Error 
Checking 


6.4  Generality,  Customizability 
and  Maintainability  of  System 


Shortcut 

The  scenario  data  from  the 
simulation  to  the  Webserver  is 
only  sent  once  without  error 
checking. 


Screens  target  one  platform  and 
one  configuration. 


Screen  information  is 
standardized  across  all  screens 
as  a  set  configuration. 


The  InterBase  version 
implemented  is  packaged  with 
JBuilder  and  is  local  version  only. 
This  limits  the  database  to  no 
remote  database  access. 


InterBase  version  is  local  access 
only. 


Design  Considerations 

The  data  link  selected  most 
probably  will  have  checksum, 
parity,  or  other  type  of  error 
checking.  Any  software  design 
effort  for  PASS  must  take  error 
checking  and  data  integrity  into 
consideration. _ 

The  screens  are  configured  for 
one  ProSuper  working  a  squadron 
of  F-16CJ  aircraft.  The  ProSuper 
staff  consists  of  two  APG 
Expeditors,  one  Specialist 
Expeditor,  one  Weapons 
Expeditor,  and  one  Debriefer. 

This  configuration  is  not 
applicable  base  wide.  The 
Maintenance  staff  should  be  fully 
customizable  in  a  PASS 
implementation  to  fit  any  staff 
configuration. _ 


The  detailed  data  in  the  table 
should  allow  for  sort,  selection, 
and  filter  capabilities.  This  would 
give  a  more  customized  and  less 
cluttered  view  of  the  data  of 
interest.  Drill-down  screens  may 
even  be  explored. _ 


The  InterBase  local  server  meets 
the  requirements  for  the  PASS 
demonstration,  but  limits  the 
flexibility  of  the  design  for  full 
PASS  implementation.  For  full 
PASS  implementation,  many 
other  database  products  are 
available  and  should  be  evaluated 
for  best  performance  and  other 
PASS  requirements. _ 


For  PASS  implementation, 
especially  for  the  integration  of 
PASS  with  IMIS  type  legacy 
systems,  conclusive  studies 
should  be  performed  on 
commercially  available  databases 
such  as  Oracle,  SQL  Server,  and 
the  full  version  of  InterBase  to 
ensure  a  complete  enterprise 
PASS  implementation  can  be 
obtained.  The  PASSReceiver 
database  should  ultimately  reside 
on  a  separate  machine  from  the 
Webserver. 
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Shortcut 

Design  Considerations 

6.5  Integration  with  IMIS  and 
IMDS  Systems 

Status  data  such  as  flight 
schedule,  location  etc  existing  in 
the  top-level  menus  for  the  users 
explored  are  simulated  data. 

For  full  PASS  implementation 
benefits,  PASS  must  integrate 
seamlessly  with  the  legacy 
systems.  These  systems  include, 
but  are  not  limited  to,  IMIS,  IMDS, 
CAMS,  CFRS,  and  G081.  The 
integration  of  the  entire 
information  network  must  be 
considered  for  both  a  home  base 
and  deployed  system. 

6.6  Webserver 

The  Microsoft  IIS  application  was 
selected  due  to  the  availability 
and  requirement  for  a  Webserver. 

For  full  PASS  implementation, 
many  other  WebServers  are 
available  and  should  be  evaluated 
for  best  performance  and  other 
PASS  requirements. 

7.  SUMMARY 

The  PASS  demonstration  design  encapsulates  and  provides  a  means  to  show  how 
PASS  could  benefit  today’s  maintenance  environment.  The  benefits  of  PASS  may  also 
be  applied  to  the  forthcoming  paperless  maintenance  environment,  such  as  the  F-22 
platform. 

The  PASS  demonstration  allows  pre-generated  scenarios  to  be  executed, 
demonstrating  real  time  situational  displays  of  how  and  when  PASS  data  is  made 
available  to  various  levels  of  maintenance  users  at  different  phases  of  the 
launch/recovery  maintenance  process. 

With  proper  scenario  generation,  the  PASS  demonstration  can  realistically  show  the 
benefits  of  a  PASS  implementation  in  any  maintenance  environment.  The  PASS 
demonstration  lays  the  groundwork  for  a  full-scale  PASS  implementation. 
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